Parallel execution of DXL scripts

Hi I am new to DXL scripting. I wanted to know how to run the DXL scripts in parallel so that can increase the performance of the DOORS. Now I am running a single DXL script as below by keeping this code in a command file and running this using a process.

%DOORS_EXE% -W -batch %DOORS_DXL_FILE% -user %DOORS_USER% -password %DOORS_PASSWORD% -logfile "%TEMP_PATH%\Logfile.log"
MaheshPatil - Mon May 16 04:17:34 EDT 2011

Re: Parallel execution of DXL scripts
Mathias Mamsch - Mon May 16 08:03:47 EDT 2011

The DOORS DXL execution engine is single threaded, meaning only one DXL can run at any time. You can do background processing in DOORS using timers and GUIs, but that will not make the DXL faster - while this only will create an illusion of multi-threading, there is still at any time only one DXL active.

So for speeding up your DXL you would need to rely either on multiple processes (like you currently do), or optimizing your DXL. Depending on the task of the DXL I had cases, where a DXL that would run 16 minutes could be reduced to 7 seconds by clever optimization or a DXL that would run several hours could be reduced to a couple of minutes.

For some tasks I am not sure if you would really have any speedup possible. For example the data transfer to the DOORS server is limited by the network ressources of the client (if only one) and the server. This means stuff like opening all modules in a database might not get a huge speedup, if you had 4 processes doing it, instead of one, since they will share their network ressources.

So what are you trying to speedup? Maybe we can help you with your specific optimization task.

Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Parallel execution of DXL scripts
llandale - Mon May 16 15:21:59 EDT 2011

Mathias Mamsch - Mon May 16 08:03:47 EDT 2011
The DOORS DXL execution engine is single threaded, meaning only one DXL can run at any time. You can do background processing in DOORS using timers and GUIs, but that will not make the DXL faster - while this only will create an illusion of multi-threading, there is still at any time only one DXL active.

So for speeding up your DXL you would need to rely either on multiple processes (like you currently do), or optimizing your DXL. Depending on the task of the DXL I had cases, where a DXL that would run 16 minutes could be reduced to 7 seconds by clever optimization or a DXL that would run several hours could be reduced to a couple of minutes.

For some tasks I am not sure if you would really have any speedup possible. For example the data transfer to the DOORS server is limited by the network ressources of the client (if only one) and the server. This means stuff like opening all modules in a database might not get a huge speedup, if you had 4 processes doing it, instead of one, since they will share their network ressources.

So what are you trying to speedup? Maybe we can help you with your specific optimization task.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

I've notice that while a module is being opened that the local PC's processors are not very busy.

I played with the notion of coordinating two DXLs running on two DOORS clients. The idea was that while one DXL was retrieving or saving data to the database the other DXL could be running and doing something relevant. I am confident that if you have 2 folders each with 100 modules, that you would get rather more throughput having 2 DOORS clients each processing just one of the folders. Having said that, you would lose some time if both sets of modules tended to be linked to the same modules, as that would mean that both clients would need to load the same modules, duplicating work.

You want to avoid the situation where both clients are retrieving data at the same time as that may cause excessive network thrashing or other stuff I don't understand. The "coordination" would be one client would set a flag saying "am loading now" and when the module was open set the flag "done loading", and neither client would "load" while the other one was. However, one client could parse the data (do whatever it wants to with the module) while the other one was loading.

  • Louie